Manipulating binary large objects

ABSTRACT

Embodiments provide automated access policy enforcement, content rule enforcement, and data transformations in a binary large object (blob) storage service. Verified and unverified clients are allowed varying degrees of access to stored blobs. In response to a read request associated with a target blob of a particular blob type, criteria from the read request are used to execute one or more transformation functions defined by the blob type to create transformed data, and the transformed data is provided to the client. In response to a write request including a target blob of a particular blob type, a set of content rules associated with the blob type is executed against the target blob. The target blob is stored based on the content rules being successfully executed.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.13/712,988 filed Dec. 13, 2012, which claims the benefit of U.S.Provisional Application No. 61/606,740 filed Mar. 5, 2012. Eachapplication is incorporated herein by reference in their respectiveentireties.

BACKGROUND

In some existing software systems, when an application such as a gameaccesses (e.g., reads and/or writes) data using a storage service, theapplication must supply all business logic related to validating,transforming, and securing that data. Further, existing binary largeobject (blob) storage systems treat blobs as opaque binary objects anddo not enable an application to access individual data elements within ablob.

SUMMARY

Embodiments of the disclosure enable automated data transformations,content rules, and/or access policies in a binary large object (blob)storage service. Blobs may be associated with blob types that definetransformation functions. A read request for a blob, or a portionthereof, is received from a client. The read request includes one ormore criteria. The blob type associated with the target blob isdetermined, and, responsive to the received read request, atransformation function defined by the determined blob type is executedbased on the criteria to create transformed data. Executing thetransformation function includes reducing one or more dimensions ofgraphical data in the target blob, applying a data reduction algorithmto data in the target blob, applying a format conversion to data in thetarget blob, and/or filtering data in the target blob. The transformeddata is provided to the client.

A blob type may be associated with a set of content rules. A writerequest containing a target blob associated with the blob type isreceived from a client. Responsive to the received write request, theset of content rules associated with the defined blob type is executedagainst the target blob in the write request. Executing the set ofcontent rules includes validating data in the target blob, classifyingdata in the target blob, and/or applying a format conversion to data inthe target blob. The target blob is stored in a memory area based on theset of content rules being successfully executed against the targetblob.

Blobs may be stored in a verified data partition or an unverified datapartition. A request associated with a target blob is received from aclient that is designated as a verified client or an unverified client.An access policy is satisfied unless (a) the client is a verifiedclient, the request is a read request for binary data, and the targetblob is stored in an unverified data partition, or (b) the client is anunverified client, the request is a write request, and the target blobis to be stored in a verified data partition. The received request isexecuted based on the access policy being satisfied.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary block diagram illustrating a user device 102interacting with a blob network service.

FIG. 2 is an exemplary flow chart illustrating operation of thecomputing device to execute a read request from a client.

FIG. 3 is an exemplary flow chart illustrating operation of thecomputing device to execute a write request from a client.

FIG. 4 is an exemplary block diagram illustrating storage of data in thememory area.

FIG. 5 is an exemplary flow chart illustrating operation of thecomputing device to apply an access policy to a client request.

Corresponding reference characters indicate corresponding partsthroughout the drawings.

DETAILED DESCRIPTION

Referring to the figures, embodiments of the disclosure enable themanipulation of binary large objects (blobs) using content rules. Insome embodiments, a blob network service 120 includes content-relatedlogic encapsulated in a content storage service to enable theabstraction of complex logic from the consumer of the data. The blobnetwork service 120 provides a processing pipeline between a client andthe blob-based data (e.g., a blob store), potentially relieving theclient of certain content processing tasks, such as format conversion,scaling, etc. The client represents any device, such as a user device102), that reads and/or writes blobs. Further, the blob network service120 may provide processing functions that are infeasible to implement ina client. For example, the blob network service 120 may verify dataexchanged between different types of devices (e.g., verified andunverified clients) to enable unverified platforms to safely share datawith verified platforms. Further, the blob network service 120 maymodify blob data in real-time based on criteria (e.g., desireddimensions and/or a desired bit rate) associated with a client.

In some embodiments, the blob network service 120 is manifested as anextensibility framework on top of an existing blob store (e.g., a filesystem, a blob service, etc.). The blob network service 120 or frameworkmakes it possible to insert filters, validators, and other processesinto the read/write pipeline for that blob store. Furthermore, the blobnetwork service 120 provides various extensibility options. For example,an image blob may, in some embodiments, allow the blob store to offerthe ability to resize images as the blobs for those images are retrievedfrom storage. As another example, a video blob may offer transcoding(e.g., converting videos from one format to another or resizing videosto fit smaller screens). Still further, a single-use blob may bedestroyed or rendered inaccessible after their contents are retrieved,etc., in some embodiments.

In another example, and as further described below, an application(e.g., a game title) writes key/value data within a single blob, but isthen able to read smaller portions of the larger blob. This allows adevice that can easily support larger bandwidth consumption to interactwith the whole portion of data, while enabling a device with lesseraccess (e.g., smaller bandwidth) the ability to make smallerreads/writes.

The blob network service 120 further provides simplicity for a user 104.By way of this framework, objects are built that enable publishers ordevelopers to introduce dynamic logic in a file that is seen only as ablob by the user 104. The system also provides a way to isolate orprovide permissions on different types of data and/or values. Thisunlocks potential for enabling scenarios across platforms that havedifferent levels of trustworthiness.

Aspects of the disclosure further determine how data is presented backto the caller. In this way, the blob network service 120 provides theability to enact specific logic or code paths depending on the type ofdata that is being requested. For example, a developer may want to putcustom operations or other logic into a specific type of container. Whenthat type of container is requested, the blob network service 120applies the process defined to that container and returns it to theconsumer in a way that the consumer does not know anything about thelogic that was used to build the container. In this example, a developermay implement many types of conditionals based on criteria presented andgive the file back to the caller where it does not require clientchanges to support.

An exemplary system provides cross-device, cross-platform, andcross-application access to per-user, per-application group data as wellas global application group data. In some embodiments, applications usethe blob network service 120 for application-managed saved applicationstate (e.g., in addition to or in lieu of console-managed savedapplications such as saved games). The blob network service 120 may beaccessed through application group-specific uniform resource locators(URLs), in which case the stored data is accessible to all current andfuture applications that have permission to access that applicationgroup.

While described with reference to games in some embodiments, aspects ofthe disclosure are operable with any form, type, or quantity ofapplications.

Referring to FIG. 1, an exemplary block diagram illustrates the userdevice 102, such as a gaming console, associated with the user 104. Theuser device 102 represents any device executing instructions (e.g., asapplication programs, operating system functionality, or both) toimplement the operations and functionality associated with the userdevice 102. The user device 102 may include a mobile computing device orany other portable device. In some embodiments, the mobile computingdevice includes a gaming console or gaming device, mobile telephone,laptop, tablet, computing pad, netbook, and/or portable media player.The user device 102 may also include less portable devices such asdesktop personal computers, kiosks, and tabletop devices. Additionally,the user device 102 may represent a group of processing units or othercomputing devices. For example, the user device 102 may be anotherservice (e.g., sending requests).

The user device 102 has at least one processor 106 and a memory area108. The user device 102 may also include at least one user interface.The processor 106 includes any quantity of processing units, and isprogrammed to execute computer-executable instructions for implementingaspects of the disclosure. The instructions may be performed by theprocessor 106 or by multiple processors executing within the user device102, or performed by a processor external to the user device 102. Insome embodiments, the processor 106 is programmed to executeinstructions such as those illustrated in the figures.

The user device 102 further has one or more computer readable media suchas the memory area 108. The memory area 108 includes any quantity ofmedia associated with or accessible by the user device 102. The memoryarea 108 may be internal to the user device 102 (as shown in FIG. 1),external to the user device 102 (not shown), or both (not shown).

The memory area 108 stores, among other data, one or more applications110. The applications 110, when executed by the processor 106, operateto perform functionality on the user device 102. Exemplary applications110 include game titles, mail application programs, web browsers,calendar application programs, address book application programs,messaging programs, media applications, location-based services, searchprograms, and the like. The applications 110 may communicate withcounterpart applications or services such as web services accessible viaa network. For example, the applications 110 may represent downloadedclient-side applications that correspond to server-side servicesexecuting in a cloud.

The user device 102 may include a graphics card for displaying data tothe user 104 and receiving data from the user 104, along withcomputer-executable instructions (e.g., a driver) for operating thegraphics card. Further, the user device 102 may include a display (e.g.,a touch screen display or natural user interface) and/orcomputer-executable instructions (e.g., a driver) for operating thedisplay. The user device 102 may also include one or more of thefollowing to provide data to the user 104 or receive data from the user104: speakers, a sound card, a camera, a microphone, a vibration motor,one or more accelerometers, a BLUETOOTH brand communication module,global positioning system (GPS) hardware, and a photoreceptive lightsensor. For example, the user 104 may input commands or manipulate databy moving the user device 102 in a particular way.

In some embodiments, the user device 102 includes a communicationsinterface such as a network interface card and/or computer-executableinstructions (e.g., a driver) for operating the network interface card.Communication between the user device 102 and other devices may occurusing any protocol or mechanism over any wired or wireless connection.In some embodiments, the communications interface is operable withnear-field communication (NFC) tags.

In exemplary embodiments, the user device 102 communicates with the blobnetwork service 120, which provides data storage and retrieval services.The user device 102 and/or an application 110 executed by the userdevice 102 may be referred to as a client to the blob network service120.

The blob network service 120 includes one or more computing devices 122.The computing device 122 represents any device executing instructions(e.g., as application programs, operating system functionality, or both)to implement the operations and functionality described herein.Additionally, the computing device 122 may represent a group ofprocessing units or other computing devices

The computing device 122 has at least one processor 124 and a memoryarea 126. The processor 124 includes any quantity of processing units,and is programmed to execute computer-executable instructions forimplementing aspects of the disclosure. The instructions may beperformed by the processor 124 or by multiple processors executingwithin the computing device 122, or performed by a processor external tothe computing device 122. In some embodiments, the processor 124 isprogrammed to execute instructions such as those illustrated in thefigures (e.g., FIG. 2, FIG. 3, and FIG. 5).

The computing device 122 further has one or more computer-readable mediasuch as the memory area 126. The memory area 126 includes any quantityof media associated with or accessible by the computing device 122. Thememory area 126 may be internal to the computing device 122 (as shown inFIG. 1), external to the computing device 122 (shown by storage area128), or both.

The memory area 126 stores one or more data records 130. While describedas “records,” the data records 130 represent any data stored in anyformat, configuration, structure, organization, or type. For example,the data records 130 may include one or more of the following: blobdata, blob type data, transformation functions, content rules, accesspolicies, text data, spreadsheet data, images, audio, video, and/ordatabase data. The data records 130 may be stored in the memory area 126as shown in FIG. 1 and/or stored in the storage area 128 external to thecomputing device 122. In some embodiments, a data record 130 has one ormore fields associated therewith. Each field corresponds to a particularelement or item of data.

The memory area 126 further stores one or more computer-executablecomponents. Exemplary components include a blob component 132, a clientinterface component 134, an access policy component 136, and a securitycomponent 138. The components, when executed by the processor 124 causethe processor 124 to enable access to data managed by computing device122, as described next with reference to the figures.

At least a portion of the functionality of the various elements in thefigures may be performed by other elements in the figures, or an entity(e.g., processor, web service, server, application program, computingdevice, etc.) not shown in the figures.

In some embodiments, the operations illustrated in the figures may beimplemented as software instructions encoded on a computer readablemedium, in hardware programmed or designed to perform the operations, orboth. For example, aspects of the disclosure may be implemented as asystem on a chip or other circuitry including a plurality ofinterconnected, electrically conductive elements.

Referring next to FIG. 2, an exemplary flow chart illustrates operationof the computing device 122 to execute a read request from a client,such as the user device 102. While the operations illustrated and/ordescribed with reference to FIG. 2 are described as being performed bythe blob network service 120 in some embodiments, the operations may beperformed by any entity. For example, one or more of the operations maybe performed by an entity remote from both the user device and thememory area 126 (and/or storage area 128).

At 202, one or more blob types are defined. For example, the user 104may create blob types representing various types of content (e.g.,video, images, audio, and/or text). Each blob type defines zero or moretransformation functions that may be executed against data stored in ablob of that type. Blob types and blobs associated therewith are storedin the memory area 126.

At 204, the computing device 122 receives, from a client, a read requestfor a target blob representing at least a portion of one or more of theblobs stored by the memory area 126. The read request includes one ormore criteria. For example, the criteria may specify one or more desiredbit rates, desired dimensions, desired quality levels (e.g., relativelevels such as low, medium, and high), and/or desired data formats.

At 206, responsive to the received read request, the computing device122 determines the blob type(s) associated with the target blob. At 208,the computing device 122 determines whether one or more transformationsare appropriate based on the criteria provided by the client. In someembodiments, a transformation is appropriate when the criteria specify adata attribute (e.g., a desired data format) that is different from acorresponding data attribute associated with the target blob, and a blobtype associated with the target blob defines a transformation functioncapable of creating output data satisfying the specified data attributebased on the target blob. In an example scenario, the client specifies afirst video encoding, and video data in the target blob is stored in asecond video encoding. If the target blob is associated with a blob typedefining a data format conversion (also known as “transcoding”) functioncapable of producing video in the first encoding based on video in thesecond encoding, the computing device 122 determines that thistransformation is appropriate.

At 210, the computing device 122 executes a transformation functiondetermined to be appropriate in the operation at 208. Execution of thetransformation function creates transformed data based on the input data(e.g., data in the target blob or the output of a previously executedtransformation function). In exemplary embodiments, transformationfunctions include reducing one or more dimensions of graphical data inthe target blob, applying a data reduction algorithm to data in thetarget blob, applying a format conversion to data in the target blob,and/or filtering data in the target blob. In some embodiments, thecomputing device 122 determines that a plurality of transformationfunctions are appropriate (e.g., scaling and converting the format of animage) and performs the operation at 210 to execute each appropriatetransformation function. At 212, when any appropriate datatransformation functions have been executed, the computing device 122provides either the transformed data or the target blob to the client.

In some embodiments, executing a transformation function based on thecriteria provided by the client enables improved computing performanceat the client. In an example scenario, the request includes criteriaspecifying desired graphical data dimensions corresponding to a displayresolution of the user device 102. The target blob includes graphicaldata (e.g., image or video data) with dimensions larger than the desireddimensions, and the computing device 122 executes a transformationfunction by scaling the graphical data to create transformed graphicaldata having dimensions smaller than the dimensions of the graphical datastored in the target blob. The transformed data is smaller in size thanthe original data and can be transmitted to the client relativelyquickly. In addition, scaling at the client may be reduced or avoided,improving rendering speed.

In some embodiments, transforming data in the target blob includesfiltering data in the target blob based on criteria such as anindication of which data elements are desired by client, one or moreaccess privileges associated with the client, and/or one or more accesscontrol lists associated with the target blob. Further, in someembodiments, a limited-use blob type is provided. In an examplescenario, a blob type defines a deactivation transformation functionthat limits the accessibility of a blob by a quantity of accesses (e.g.,one or more) and/or by a period of time. When a read request for a blobassociated with a limited-use blob type is received, the computingdevice 122 executes the deactivation transformation function, whichdeactivates the target blob if the quantity and/or time limit have beenreached. Once deactivated, the target blob is subsequently inaccessibleto the client.

Referring next to FIG. 3, an exemplary flow chart illustrates operationof the computing device 122 to execute a write request from a client.While the operations illustrated and/or described with reference to FIG.3 are described as being performed by the blob network service 120 insome embodiments, the operations may be performed by any entity. Forexample, one or more of the operations may be performed by an entityremote from both the user device 104 and the memory area 126 (and/orstorage area 128).

At 302, one or more blob types are defined. Each blob type is associatedwith a set of zero or more content rules to be executed against inputdata prior to storing the input data in a blob of that type. Forexample, a content rule may specify a particular data format or aparticular type of data validation. Blob types and blobs associatedtherewith are stored in the memory area 126.

At 304, the computing device 122 receives, from a client, a writerequest containing a target blob associated with a defined blob type. At306, responsive to the received write request, the computing device 122determines the blob type associated with the target blob.

At 308, the computing device 122 executes each content rule in the setof content rules associated with the determined blob type against thetarget blob. Executing a content rule includes, for example, validatingdata in the target blob, classifying data in the target blob, and/orapplying a format conversion to data in the target blob.

In an example scenario, a content rule specifies a data format (e.g., avideo encoding). If the data in the target blob is in a data formatother than the specified data format, and a format conversion betweenthe two data formats is available, the computing device 122 executes theformat conversion to create data in the specified data format. In someembodiments, a predetermined default data format is associated with ablob type, and a content rule associated with the blob type specifiesthe default data format for all data stored in blobs of that blob type.For example, a content rule may specify a predetermined default encodingfor video data stored in the blob network service 120. The computingdevice 122 executes this content rule with respect to a target blobincluding video data in a different encoding by creating video dataencoded in the default encoding based on the video data from the targetblob.

In some embodiments, a content rule specifies a data validation to beperformed on the target blob prior to storing the target blob. Suchembodiments may provide a level of assurance that data subsequently readfrom a blob conforms to an expected structure, is free of malicioussoftware, etc. In an example scenario, the computing device 122validates data in the target blob based on a set of legal characters, anexpected data structure, and/or the presence of executable instructionsin the target blob. In these examples, the validation fails if thetarget blob includes a character other than those in the set of legalcharacters, if the target blob does not match the expected datastructure, or if the target blob includes executable instructions,respectively.

In some embodiments, the computing device 122 executes a content rule atleast in part by validating data in the target blob based on a quantityof data in the target blob and a quantity of available storage in thememory area 126 and/or storage area 128. The quantity of availablestorage may be computed as all unallocated storage, or may be computedbased on one or more size-based and/or rate-based storage quotas. Forexample, the quantity of data stored and/or the frequency of accessrequests may be limited per user 104, per application or game title,and/or per application or game title group, as described next withreference to FIG. 4.

Referring next to FIG. 4, an exemplary diagram illustrates partitionedstorage of data in the memory area 126. In addition, or alternatively,the storage techniques described may be applied to storage of data inthe storage area 128.

The memory area 126 includes a Title Group storage 402, which is aportion of the memory area 126 that is associated with a group of one ormore game titles. The memory area 126 may include any quantity of TitleGroup storages 402, each of which is associated with a Title Groupidentifier (ID) unique among other Title Group storages 402. Whenaccessing data using the blob network service 120, a game title submitsto the computing device 122 an access request specifying a Title GroupID, and the computing device 122 reads from, or writes to, the TitleGroup storage 402 associated with the specified Title Group ID.

The Title Group storage 402 includes a Title User storage 404 and aTitle Global storage 406. A game title stores data that is relevant toall users 104 of the game title and/or Title Group in the Title Globalstorage 406, and stores data that is relevant to each individual user104 of the game title and/or Title Group in the Title User storage 404.

In some embodiments, one or more quotas are associated with the TitleGroup store 402, the Title User storage 404, the Title Global storage406, and/or some portion thereof. An exemplary set of quota definitionsis illustrated in Table 1 below.

TABLE 1 Exemplary Set of Quota Definitions. Limit (Quota) Value TitleGlobal Limit 150 megabytes (MB) per Title Group per title Title UserData Limit 250 MB per Title Group per user Max Individual Binary File(global) 150 MB Max Individual Binary File (user) 250 MB Max IndividualJSON File  4 MB Max Individual CONFIG File  1 MB Max Number of Files(global/user) 5000 Read Requests (avg. per 1 hour/session) 1 request perminute (per Title Group per user) Write Requests (avg. per 1 1 requestper minute (per Title hour/session) Group per user)

Using the quotas shown in Table 1 as an example, when the computingdevice 122 receives a write request associated with a particular TitleGroup and user 104, the computing device 122 identifies the Title Userstorage 404 corresponding to that Title Group and user 104. Thecomputing device 122 validates the target blob included in the writerequest by determining whether the size of the target blob is less thanor equal to the available storage within the identified Title Userstorage 404, where the available storage is calculated as 250 megabytes(MB) (the Title User Data Limit size-based quota in Table 1) minus thecurrently allocated storage within the identified Title User storage404. If so, the validation based on the Title User Data Limit size-basedquota is successful. Otherwise, the validation is unsuccessful.

As another example, the computing device 122 may validate the targetblob in part by calculating the current write request rate (e.g., anaverage request rate over the previous hour and/or within the currentsession) associated with the Title Group and user 104, and determiningwhether the current write request rate is less than or equal to onerequest per minute (the Write Request rate-based quota in Table 1). Ifso, the validation based on the Write Request rate-based quota issuccessful. Otherwise, the validation is unsuccessful.

Referring again to FIG. 3, in some embodiments, executing a content ruleincludes classifying data in the target blob. Classification may beapplied to identify the subject and/or meaning of textual data, theappropriateness of graphical data (e.g., image data and/or video data)for one or more audiences, the presence of copyright-protected data,and/or any characteristics relevant to operation of the blob networkservice 120. A classification content rule may fail based on theclassification associated with a target blob. For example, a target blobcontaining graphical data may be classified by a classification contentrule as inappropriate content, in which case the classification contentrule fails. In addition, or alternatively, such classifications may beassociated with the target blob and subsequently used for reviewing,filtering, and/or categorizing blobs.

In some scenarios, executing a content rule at 308 fails, indicatingthat the content rule is not satisfied by the target blob in the writerequest. For example, the computing device 122 may be unable to convertdata in the target blob to a data format specified by a content rule, ordata validation may fail due to illegal characters, executable code,etc. At 310, when a content rule is not satisfied, the computing device122 reports a content rule failure, and the target blob is not stored.The content rule failure may be reported, for example, by denying thewrite request (e.g., transmitting the failure to the client), by loggingthe failure, and/or by notifying an administrator of the blob networkservice 120 of the failure.

If no failures occur, at 312, the computing device 122 stores the targetblob in the memory area 126 based on the set of content rules beingsuccessfully executed against the target blob. In some embodiments, theTitle User storage 404 is divided into two or more partitions, such as averified (e.g., trusted) data partition 408 and an unverified (e.g.,untrusted) data partition 410. Within a write request, a client mayspecify a location (e.g., a path) within Title Group storage 402 towhich a target blob is to be written; this location may include areference to the verified data partition 408 and/or the unverified datapartition 410. As described below with reference to FIG. 5, thecomputing device 122 may enforce an access policy governing whichportions of the Title User storage 404 a client is allowed to access,and the target blob is stored based on determining that the accesspolicy is satisfied.

Generally, at least some data (e.g., binary data) within the unverifieddata partition 410 is not normally or typically accessible by verifiedclients, protecting the verified clients from being compromised bymalicious data written by unverified clients. In some embodiments, thecomputing device 122 allows a blob initially stored in the unverifieddata partition 410 to be accessed as verified data. If the target blobis stored in the unverified data partition 410, at 314, the computingdevice 122 verifies the data within the target blob. As an example, thecomputing device 122 may verify the data by determining whether thetarget blob includes any potentially malicious data, such as executableinstructions, values that are outside expected value ranges, and/orcharacters that are outside a set of expected characters. There may be acheck done, for example, on data written into each location based on theblob type. If the verification is successful, the target blob isconsidered free of malicious data, and at 316, the computing device 122designates the blob as verified. If the verification is unsuccessful, at318, the computing device 122 designates the blob as unverified. Byvalidating that the data meets the criteria of the target location,aspects of the disclosure provide a conduit for sharing informationbetween verified and unverified platforms without compromising thesecurity of verified platforms.

Referring next to FIG. 5, an exemplary flow chart illustrates operationof the computing device 122 to apply an access policy to a clientrequest. While the operations illustrated and/or described withreference to FIG. 5 are described as being performed by the blob networkservice 120 in some embodiments, the operations may be performed by anyentity. For example, one or more of the operations may be performed byan entity remote from both the user device and the memory area 126(and/or storage area 128).

At 502, the computing device 122 receives an access request (e.g., awrite request or a read request) associated with a target blob from aclient. At 504, the computing device 122 designates the client as eithera verified client or an unverified client. For example, the computingdevice 122 may identify a client account associated with the client andread from the client account a designation of whether the client isverified or unverified. In some embodiments, the client provides one ormore security credentials (e.g., within the access request or whenestablishing a communication session with the computing device 122).Security credentials may include, for example, a client identifier, anelectronic signature, a cryptographic key, and/or any other datasuitable for identifying the client. The computing device 122 designatesthe client as verified or unverified based on the security credentials.

The computing device 122 determines whether the access policy issatisfied based on the access request and the designation of the client.If the access policy is satisfied, at 506, the computing device 122executes the request based on the satisfied access policy. For example,the computing device 122 may execute a read request as described abovewith reference to FIG. 2 or execute a write request as described abovewith reference to FIG. 3. If the access policy is not satisfied, at 508,the computing device 122 denies the request. For example, the computingdevice 122 may deny the request at least in part by transmitting anaccess policy failure notification to the client.

Referring again to FIG. 4, in exemplary embodiments, the verified datapartition 408 and the unverified data partition 410 include binary data412 and JAVASCRIPT Object Notation (JSON) data 414. In addition, oralternatively, the partitions may include other non-binary data (notshown), such as textual data, extensible markup language (XML) data,configuration data, and/or any other non-binary data suitable for usewith the system described. The access policy is satisfied, in someembodiments, unless either a) the client is verified, the request is aread request for binary data 412, and the target blob is stored in theunverified data partition 410, or b) the client is unverified, therequest is a write request, and the target blob is to be stored in theverified data partition 408.

Additional Exemplary Implementations

Exemplary blobs processed by the blob network service 120 include, butare not limited to, Binary Blobs, JSON Blobs, or Configuration Blobs.Binary Blobs, for example, store data of any type (e.g., binary, text,XML, etc.), provide basic read/write semantics, support the hypertexttransfer protocol (HTTP) Range header to allow partial/blocked readsfrom large blobs, and support multi-block uploads for large files (e.g.,larger than 4 MB in size). The blob network service 120 treats BinaryBlobs as opaque data, but applications are free to store any type ofdata in these blobs.

JSON Blobs, as another example, store JSON objects, enforce the JSONgrammar on blobs uploaded to the service, enforce maximum key/valuelengths, maximum array size, maximum number of object properties, etc.,and provide partial read support by allowing callers to request that aspecific sub-hierarchy of the larger JSON object be returned. JSON Blobsprovide a way to safely share data between unverified and verifiedplatforms. The blob network service 120 verifies that uploaded JSONblobs adhere to the following exemplary rules and restrictions:

1. The blob content contains valid JSON according to the JSONspecification.

2. Keys are limited to 64 bytes.

3. String values are limited to 1024 bytes.

4. Maximum object depth is 16.

5. Maximum array size is 1024.

6. Maximum number of keys in an object is 1024.

JSON Blobs also support a partial-download feature. This is used toretrieve a small part of a larger JSON object and may be used, forexample, by bandwidth-constrained platforms such as mobile devices.Similar functionality is available for uploading or modifying smallerpieces of a large JSON Blob.

Callers can select the sub-node for return by using the “select” or“return” query parameter. An exemplary URL is shown below. This URLreturns the contents of the “quests” object inside of the fourth entryin the “levels” array.

GET/users/xuid(1234)/storage/titlestorage/titlegroups/5678/data/save1.dat,json?select=levels[3].quests

Configuration Blobs, as another example, are read-only (e.g., for gametitles) JSON objects, writeable only by the publisher, and have specialkeys in the JSON object that allow the blob network service 120 toreturn different JSON values based on information about the incomingcall (e.g., randomized based on user 104 or request, locale, title id,etc.). Configuration Blobs are stored in a global data store and arelimited to 64 kilobytes (kb) in size in some embodiments.

The blob network service 120 allows data to be shared across gamingapplications and platforms by way of Title Group-specific data. TitleGroup-specific data is accessed using uniform resource identifiers(URIs) containing a Title Group ID. Title Group-specific data can beshared across any number of titles and platforms in some embodiments, aslong as those titles have been given permissions to access the data inthe Title Group Access Control List (ACL) configuration.

The Title Group Client library is responsible for parsing andinterpreting the ACL. The blob network service 120 supplies the logicrelated to the claims and permissions. The client library, for example,is the component that applies the implicit “deny all” rule at the end ofthe ACL.

In some embodiments, the blob network service 120 enforces a size-basedquota on the data store. The quotas vary based on the type of data(e.g., per-user or global) being accessed and are specified in the titlegroup configuration.

Each memory area 126 or storage area 128 is configured with a settingsdocument unique to that store (e.g., unique among other stores). In someembodiments, the settings document is composed of two elements: ACL(e.g., read/write permissions applied to prefixed sets of URLs on aper-title basis) and quota configuration (e.g., maximum amount of datathat can be stored in per-user and global stores). The Title GroupSystem maintains the setting document for Title Group-based stores.

Exemplary application programming interfaces (APIs) supported in someembodiments are shown in Appendix A.

Exemplary Operating Environment

Exemplary computer readable media include flash memory drives, digitalversatile discs (DVDs), compact discs (CDs), floppy disks, and tapecassettes. By way of example and not limitation, computer readable mediacomprise computer storage media and communication media. Computerstorage media include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer readable instructions, data structures,program modules or other data. Computer storage media are tangible andare mutually exclusive to communication media. In some embodiments,computer storage media are implemented in hardware. Exemplary computerstorage media include hard disks, flash drives, and other solid-statememory. In contrast, communication media typically embody computerreadable instructions, data structures, program modules, or other datain a modulated data signal such as a carrier wave or other transportmechanism and include any information delivery media.

Although described in connection with an exemplary computing systemenvironment, embodiments of the invention are operational with numerousother general purpose or special purpose computing system environmentsor configurations. Examples of well-known computing systems,environments, and/or configurations that may be suitable for use withaspects of the invention include, but are not limited to, mobilecomputing devices, personal computers, server computers, hand-held orlaptop devices, multiprocessor systems, gaming consoles,microprocessor-based systems, set top boxes, programmable consumerelectronics, mobile telephones, network PCs, minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices, and the like. Such systems or devices mayaccept input from the user in any way, including from input devices suchas a keyboard or pointing device, via gesture input, and/or via voiceinput.

In some embodiments, the processors 106, 124 represent an implementationof analog techniques to perform the operations described herein. Forexample, the operations may be performed by an analog computing deviceand/or a digital computing device.

Embodiments of the invention may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more computers or other devices. The computer-executableinstructions may be organized into one or more computer-executablecomponents or modules. Generally, program modules include, but are notlimited to, routines, programs, objects, components, and data structuresthat perform particular tasks or implement particular abstract datatypes. Aspects of the invention may be implemented with any number andorganization of such components or modules. For example, aspects of theinvention are not limited to the specific computer-executableinstructions or the specific components or modules illustrated in thefigures and described herein. Other embodiments of the invention mayinclude different computer-executable instructions or components havingmore or less functionality than illustrated and described herein.

Aspects of the invention transform a general-purpose computer into aspecial-purpose computing device when configured to execute theinstructions described herein.

The order of execution or performance of the operations in embodimentsof the invention illustrated and described herein is not essential,unless otherwise specified. That is, the operations may be performed inany order, unless otherwise specified, and embodiments of the inventionmay include additional or fewer operations than those disclosed herein.For example, it is contemplated that executing or performing aparticular operation before, contemporaneously with, or after anotheroperation is within the scope of aspects of the invention.

Embodiments have been described with reference to data monitored and/orcollected from users 104. In some embodiments, notice may be provided tothe users 104 of the collection of the data (e.g., via a dialog box orpreference setting) and users 104 are given the opportunity to give ordeny consent for the monitoring and/or collection. The consent may takethe form of opt-in consent or opt-out consent.

When introducing elements of aspects of the invention or the embodimentsthereof, the articles “a,” “an,” “the,” and “said” are intended to meanthat there are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements. Theterm “exemplary” is intended to mean “an example of” The phrase “one ormore of the following: A, B, and C” means “at least one of A and/or atleast one of B and/or at least one of C.”

Having described aspects of the invention in detail, it will be apparentthat modifications and variations are possible without departing fromthe scope of aspects of the invention as defined in the appended claims.As various changes could be made in the above constructions, products,and methods without departing from the scope of aspects of theinvention, it is intended that all matter contained in the abovedescription and shown in the accompanying drawings shall be interpretedas illustrative and not in a limiting sense.

APPENDIX A

The following application programming interfaces (APIs) are supported insome embodiments.

List—Enumerates the blobs under the given path. If no path is given, alisting of all of the blobs in the data area is returned.

Methods associated with List: GET. Exemplary parameters are shown inTable 2 below.

TABLE 2 Exemplary Parameters for List. Data Type URI Per-User,/users/xuid({xuid})/storage/titlestorage/ Per-Title titlegroups/{titleGroupId}/data/{path} Group Global /media/titlegroups/{titleGroupId}/Title storage/data/{path} Group

Download/Upload/Delete—Downloads, uploads, or deletes data at the givenlocation, depending on the HTTP method.

Methods associated with Download/Upload/Delete: GET, PUT, DELETE.Exemplary parameters are shown in Table 3 below.

TABLE 3 Exemplary Parameters for Download/Upload/Delete. Data Type URIPer-User, /users/xuid(xuid)/storage/titlestorage/titlegroups/ Per-Title{titleGroupId}/data/{pathFileNameAndType} Group Global/media/titlegroups/{titleGroupId}/storage/ Titledata/{pathFileNameAndType} Group

GetProperties—Gets the properties for the data type, such as the quota.

Methods associated with GetProperties: GET. Exemplary parameters areshown in Table 4 below.

TABLE 4 Exemplary Parameters for GetProperties. Data Type URI Per-User,Per-Title Group /users/xuid(xuid)/storage/titlestorage/titlegroups/{titleGroupId} Global Title Group/media/titlegroups/{titleGroupId}/storage

1-20. (canceled)
 21. A user device comprising: a memory area storing oneor more applications, the one or more applications configured to performone or more functionalities of the user device; and a processorconfigured to: generate a read request for a target blob associated withan application of the one or more applications, the target blobrepresenting at least a portion of one or more blobs stored at a networkservice, the read request including one or more criteria; transmit, tothe network service, the read request, such that the network service isconfigured to create transformed data by determining a blob typeassociated with the target blob based on the criteria, and executing atransformation function based on the determined blob type associatedwith the target blob, wherein executing the transformation functionincludes one or more of the following: reducing one or more dimensionsof graphical data in the target blob, applying a data reductionalgorithm to data in the target blob, applying a format conversion todata in the target blob, and filtering data in the target blob; andreceive the transformed data.
 22. The user device of claim 21, whereinthe processor is configured to generate the read request to include theone or more criteria, such that the one or more criteria are associatedwith one or more of the following: a desired bit rate, a desireddimension, a desired quality level, and a desired data format.
 23. Theuser device of claim 21, wherein the processor is configured to generatethe read request for the target blob, wherein the target blob includesvideo data having first dimensions, and receive the transformed data,wherein the transformed data includes video data having seconddimensions smaller than the first dimensions.
 24. The user device ofclaim 21, wherein the processor is configured to: generate the readrequest for the target blob to include the one or more criteria, whereinthe target blob includes data in a first data format, and the one ormore criteria are associated with a second desired data format; andreceive the transformed data, wherein the transformed data includes datain the second data format.
 25. The user device of claim 21, wherein,upon receiving the transformed data, the target blob is inaccessible tothe user device.
 26. The user device of claim 21, wherein the userdevice is associated with one or more access privileges, and at leastsome data associated with the target blob is filtered based on the oneor more access privileges.
 27. The user device of claim 21, wherein theprocessor is configured to: create one or more blob types representingone or more types of content, the one or more blob types associated withzero or more transformation functions; and transmit, to the networkservice, the one or more blob types, such that the network service isconfigured to execute the zero or more transformation functions.
 28. Ina computing environment, a system comprising: a processor; and a memorydevice comprising computer-executable instructions, the memory devicecoupled to the processor such that the processor is configured toexecute the computer-executable instructions to: generate a writerequest for a target blob, the target blob associated with a definedblob type; and transmit, to a network service, the write request, suchthat the network service is configured to execute a set of content rulesassociated with the target blob and, on condition that the set ofcontent rules are successfully executed, store the target blob in amemory area based on the set of content rules, wherein executing thecontent rules includes one or more of the following: validating data inthe target blob, classifying data in the target blob, and applying aformat conversion to data in the target blob.
 29. The system of claim28, wherein the target blob includes video data encoded in a firstformat, and the write request is transmitted to the network device suchthat the network device applies a format conversion to the video data tocreate video data encoded in a second format.
 30. The system of claim28, wherein the target blob includes video data encoded in a firstformat, and the write request is transmitted to the network device suchthat the network device applies a format conversion to the video data tocreate video data encoded in a predetermined default format.
 31. Thesystem of claim 28, wherein the write request is transmitted to thenetwork device such that the network device validates data in the targetblob based on one or more of the following: a set of legal characters,an expected data structure, the presence of executable instructions inthe target blob, a size-based storage quota and a rate-based storagequota.
 32. The system of claim 28, wherein the target blob includesgraphical data, and the write request is transmitted to the networkdevice such that the network device classifies the graphical data. 33.The system of claim 28, wherein the memory area includes a verified datapartition and an unverified data partition, and the write request istransmitted to the network device such that the network device storesthe target blob in the memory area on condition that an access policy issatisfied, wherein the access policy is satisfied on condition that oneof the following is true: the client device is a verified client, andthe client device is an unverified client and the target blob isassociated with the unverified data partition.
 34. The system of claim28, wherein generating the write request comprises specifying a locationwithin the memory area to write the target blob.
 35. The system of claim28, wherein generating the write request comprises identifying areference to one of a verified data partition and an unverified datapartition.
 36. A method comprising: generating a read request for atarget blob representing at least a portion of one or more blobs storedat a network service, the read request including one or more criteria;transmitting, to the network service, the read request, such that thenetwork service is configured to create transformed data by determininga blob type associated with the target blob based on the criteria, andexecuting a transformation function based on the determined blob typeassociated with the target blob, wherein executing the transformationfunction includes one or more of the following: reducing one or moredimensions of graphical data in the target blob, applying a datareduction algorithm to data in the target blob, applying a formatconversion to data in the target blob, and filtering data in the targetblob; and receiving the transformed data.
 37. The method of claim 36,wherein the read request is generated to include the one or morecriteria, wherein the one or more criteria is associated with one ormore of the following: a desired bit rate, a desired dimension, adesired quality level, and a desired data format.
 38. The method ofclaim 36, wherein the read request is generated to include the one ormore criteria, the target blob includes data in a first data format, theone or more criteria is associated with a second desired data format,and the received transformed data is in the second data format.
 39. Themethod of claim 36, further comprising associating the user device withone or more access privileges, wherein the at least some data in thetarget blob is filtered based on the one or more access privileges. 40.The method of claim 36, further comprising: creating one or more blobtypes representing one or more types of content, the one or more blobtypes associated with zero or more transformation functions; andtransmitting, to the network service, the one or more blob types, suchthat the network service is configured to execute the zero or moretransformation functions.